As semiconductor technology continues to inch closer to practical limitations in terms of increases in clock speed, architects are increasingly focusing on parallelism in processor architectures to obtain performance improvements. At the chip level, multiple processing cores are often disposed on the same chip, functioning in much the same manner as separate processor chips, or to some extent, as completely separate computers. In addition, even within cores, parallelism is employed through the use of multiple execution units that are specialized to handle certain types of operations. Pipelining is also employed in many instances so that certain operations that may take multiple clock cycles to perform are broken up into stages, enabling other operations to be started prior to completion of earlier operations. Multithreading is also employed to enable multiple instruction streams to be processed in parallel, enabling more overall work to performed in any given clock cycle.
One area where parallelism continues to be exploited is in the area of execution units, e.g., fixed point or floating point execution units. Many floating point execution units, for example, are deeply pipelined. However, while pipelining can improve performance, pipelining is most efficient when the instructions processed by a pipeline are not dependent on one another, e.g., where a later instruction does not use the result of an earlier instruction. Whenever an instruction operates on the result of another instruction, typically the later instruction cannot enter the pipeline until the earlier instruction has exited the pipeline and calculated its result. The later instruction is said to be dependent on the earlier instruction, and phenomenon of stalling the later instruction waiting for the result of an earlier instruction is said to introduce “bubbles,” or cycles where no productive operations are being performed, into the pipeline.
One technique that may be used to extract higher utilization from a pipelined execution unit and remove unused bubbles is to introduce multi-threading. In this way, other threads are able to issue instructions into the unused slots in the pipeline, which drives the utilization and hence the aggregate throughput up. Another popular technique for increasing performance is to use a single instruction multiple data (SIMD) architecture, which is also referred to as ‘vectorizing’ the data. In this manner, operations are performed on multiple data elements at the same time, and in response to the same SIMD instruction. A SIMD or vector execution unit typically includes multiple processing lanes that handle different datapoints in a vector and perform similar operations on all of the datapoints at the same time. For example, for an architecture that relies on quad(4)word vectors, an SIMD or vector execution unit may include four processing lanes that perform the identical operations on the four words in each vector.
The aforementioned techniques may also be combined, resulting in a multi-threaded vector execution unit architecture that enables multiple threads to issue SIMD instructions to an SIMD execution unit to process “vectors” of data points at the same time.
In addition, it is also possible to employ multiple execution units in the same processor to provide additional parallelization. The multiple execution units may be specialized to handle different types of instructions, or may be similarly configured to process the same types of instructions.
Typically, a scheduling algorithm is utilized in connection with issue logic to ensure that each thread in a multi-threaded architecture is able to proceed at a reasonable rate, with the number of bubbles in the execution unit pipeline(s) kept at a minimum. In addition, when multiple execution units are used, the issuance of instructions to such execution units may be handled by the same issue unit, or alternatively by separate issue units.
Another technique that may be used to improve the performance of a processor is to employ a microcode unit or sequencer to automatically generate instructions for execution by an execution unit. A microcode unit or sequencer responds to commands, e.g., via dedicated instructions in an instruction set, and in response, outputs a sequence of instructions to be executed by the processor. In much the same way that a software procedure can be used to perform a repeatable sequence of steps in response to a procedure call in a software program, a microcode unit or sequencer can be triggered by a command or instruction to perform a repeatable operation.
While the aforementioned techniques have been applied to improve the throughput of instructions in a processor and minimize pipeline bubbles, areas for improvement still exist. For example, in some instances the data stored in a register file may need to be preprocessed before it can be used by instructions that reference the data. In floating point execution units, denormal floating point values stored in a floating point register file may need to be normalized before use. A denormal number is a non-zero number that is smaller than the smallest normal number supported in a floating point system, and is used to fill an underflow gap around zero in floating point arithmetic. In many floating point execution units, denormal numbers must be normalized by shifting the significand or fraction portions of such numbers one bit to the left and decrementing the corresponding exponent portions.
In conventional floating point execution units, whenever a denormal floating point number is referenced as an operand of a floating point instruction, the floating point execution unit is required to normalize the number and reexecute the floating point instruction. Doing so typically requires a flush of the pipeline, normalization of the denormal value, storage of the normalized value back in the register file or in a scratch register, and reissuing the original floating point instruction, all of which constitute a significant performance hit.
Other types of data stored in a register file may also be suboptimal, and require preprocessing prior to use. For example, data may be stored in a register file in a compressed or packed format, and may need to be decompressed or unpacked prior to use. Data may also be stored in an encrypted format and require decryption prior to use. In both instances, similar performance penalties may result if a floating point instruction attempts to use such data prior to decompressing or decrypting the data.
Therefore, a significant need continues to exist in the art for a manner of minimizing the performance overhead associated with preprocessing data stored in a register file.